This is a lost notify deadlock bug.
When log4j works with AsyncAppender,
log appender threads put log events
into a buffer and wait when the buffer is full, and a dispatcher thread
dispatches events in the buffer. But when
an exception happens inside the dispatch thread, the dispatcher thread
just goes down and there will be no one to deal with the full filled
buffer and notify the
waiting appender threads. So the waiting appender threads keep waiting
forever.
The following is an example of starvation thread dump:
Thread[main,5,main] is waiting:More details about this bug are at LOG4J-50463 JIRA page.
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1186)
at java.lang.Thread.join(Thread.java:1239)
at org.apache.log4j.Test50463.logToFillBuffer(Test50463.java:78)
at org.apache.log4j.Test50463.main(Test50463.java:62)
Thread[Thread-11,5,main] is waiting:
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.apache.log4j.AsyncAppender.append(AsyncAppender.java:104)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:65)
at org.apache.log4j.Category.callAppenders(Category.java:203)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.error(Category.java:302)
at org.apache.log4j.Test50463$FillBufferThread.run(Test50463.java:95)
This bug is reproduced under log4j 1.2.14 and JDK 1.6.0_33.
Execute
the following scripts to run the test to reproduce the bug (assume the
location of the log4j test project is log4j_test_home).
Linux:
${log4j_test_home}/scripts/50463.sh
[--monitoroff]
Windows:
%log4j_test_home%\scripts\50463.bat
[--monitoroff]
Example:
Use monitor to report and terminate the program when forever waiting
happens:
${log4j_test_home}/scripts/50463.sh
Turn off monitor:
${log4j_test_home}/scripts/50463.sh
--monitoroff
| Option | Function |
| --monitoroff, -mo | Turn off to stop reporting bug messages and ending program
when test runs into the expected concurrency bug which is a forever waiting. User has to terminate the program manually when this option is set. |